Read the original article here.

---

Okay, here is the detailed educational resource on Polymorphic Code, structured for "The Forbidden Code: Underground Programming Techniques They Won’t Teach You in School".

---

Polymorphic Code: The Art of Code Mutation for Evasion

Welcome, initiates, to the deeper layers of code manipulation – techniques often whispered about in dark corners, rarely taught in conventional classrooms, and frequently leveraged in the digital underground. Our journey begins with a fundamental concept used to cloak malicious intent: Polymorphic Code.

Imagine writing a sentence, but every time you write it, the words are different, the structure shifts, yet the meaning remains precisely the same. That's the essence of polymorphic code. It's code that changes its appearance (its raw machine instructions) with every execution or propagation, while its core function – the task it performs – stays constant.

Think of simple math: 3 + 1 and 6 - 2. These are vastly different instructions at the machine level, yet they both achieve the same outcome: 4. Polymorphic code employs similar trickery on a much larger, dynamic scale.

Why would a programmer want code to constantly change? In the realm of "Forbidden Code," the answer is almost always: evasion. Specifically, evading detection by security software.

The Core Mechanism: Encrypt, Decrypt, Mutate

At its heart, polymorphic code typically relies on a combination of encryption and self-modification.

1. The Payload: The actual malicious code – the part that performs the unwanted action (stealing data, encrypting files, spreading, etc.) – is often called the "payload".

   Payload: In the context of malware or shellcode, the payload is the core component that performs the actual harmful action. It's the part you want to hide.

2. Encryption: To hide the static signature of the payload, it is encrypted. The encrypted payload looks like meaningless random data to a simple scanner.

   Encryption: The process of converting plain text or data into a coded form (ciphertext) that can only be decoded by someone with the correct key.

3. The Decryptor: Since the CPU cannot execute encrypted data, a small piece of code called a "decryptor" is prepended or included with the encrypted payload. When the polymorphic code is executed, the decryptor runs first. Its job is to decrypt the payload in memory and then transfer execution to the now-decrypted payload.

   Decryptor: A small routine or block of code that contains the necessary logic and key to decrypt an associated encrypted payload in memory, making it executable.

So far, this is just basic self-decrypting code. A standard anti-virus scanner could easily create a signature for the static decryptor code. This is where polymorphism comes in.

The Polymorphic Engine: The Heart of Mutation

To achieve true polymorphism, the decryptor itself must change with each new copy or execution of the code. This is managed by a component known as the "polymorphic engine".

Polymorphic Engine (or Mutator): A sophisticated routine included within the polymorphic code that generates new, functionally identical variations of the decryptor code and potentially changes the encryption key, then encrypts the payload using the new key. This process occurs each time a new copy of the code is created (e.g., when a virus infects a new file).

Here's how the engine works and what kind of mutations it performs on the decryptor:

1. Generation: The engine contains algorithms to generate a new decryptor routine. This new routine will perform the exact same decryption logic as the old one, but use different instructions, register usage, or instruction order.
2. Re-encryption: The engine may also generate a new encryption key. It then encrypts the original payload using this new key.
3. Assembly: The engine combines the newly generated decryptor (which includes the new key) with the newly encrypted payload to form a new, unique instance of the polymorphic code.

Examples of Decryptor Mutation Techniques:

• Instruction Substitution: Replacing one instruction sequence with another that does the same thing. For example, replacing ADD EAX, 5 with SUB EAX, -5 or a sequence like PUSH 5; POP EAX; ADD EAX, [ESP+0]; ADD EAX, [ESP+4]... (oversimplified, but illustrates adding complexity).
• Register Swapping/Usage Changes: Using different registers for temporary storage or calculations (e.g., using EBX instead of ECX for a loop counter).
• Junk Code Insertion: Inserting meaningless instructions (like NOP - No Operation) or instructions that perform calculations but whose results are never used and don't affect the control flow or decryption logic. These are purely there to change the byte pattern.
• Instruction Reordering: Changing the order of independent instructions that don't rely on each other's immediate results.
• Control Flow Obfuscation: Using jumps and conditional statements in complex ways to reach the same decryption logic, making static analysis harder.
• Varying Encryption Keys: While the decryption algorithm (like XOR, ADD/SUB loops) might be similar across instances, the key used can be different, requiring the generated decryptor to contain that specific key.

By implementing these techniques, the byte pattern of the decryptor changes significantly with every new instance. This makes it incredibly difficult for security software relying on fixed "signatures" (specific sequences of bytes) to identify the malicious code.

Why This is "Forbidden Code": Evading Detection

The primary reason polymorphic code falls under the umbrella of "Forbidden Code" is its effectiveness in bypassing traditional security measures, specifically signature-based detection.

Signature-Based Detection: A method used by anti-virus and intrusion detection systems that identifies malicious code by comparing patterns (signatures - sequences of bytes or code) found in scanned files or network traffic against a database of known malicious patterns.

When a security product only uses signatures, it's looking for exact or near-exact matches to previously identified threats. A polymorphic virus, worm, or shellcode constantly changes its signature (specifically, the signature of its decryptor). A scanner might see 0x41 0x52 0x8B 0xC0 ... in one sample, and 0x90 0x90 0x53 0x8B 0xE0 ... in the next, even though both samples perform the exact same malicious function.

This forces security vendors into a difficult arms race:

• They try to create signatures for common patterns within the mutating decryptors (heuristic analysis).
• They attempt more sophisticated analysis to understand the behavior rather than just the signature.

Defending Against Polymorphism: The Arms Race Continues

Security researchers and anti-malware developers have developed techniques specifically to combat polymorphic code:

1. Advanced Pattern Analysis: Instead of looking for single, long signatures, security software tries to identify shorter, common instruction sequences, logical structures, or mathematical properties that persist across different mutations of the decryptor. This is harder and prone to false positives.

2. Emulation and Sandboxing: This is one of the most effective techniques. Security software can execute suspicious code in a safe, virtual environment (a sandbox).

   Emulation (in security context): The process of running suspicious code within a simulated CPU and memory environment that mimics a real system. This allows the security software to observe the code's behavior without risking the actual system.

   Sandbox: An isolated environment (often virtualized) where suspicious programs can be executed and observed without affecting the host system or network.

   When polymorphic code runs in an emulator or sandbox, the decryptor executes, decrypts the payload in the virtual memory, and transfers control to it. At this point, the original, static payload is exposed in the emulator's memory. The security software can then scan this decrypted payload using traditional static signatures. If the payload itself doesn't mutate (which is the case for purely polymorphic code, unlike metamorphic code), it can often be detected at this stage.

Polymorphism vs. Metamorphism: A Key Distinction

It's crucial to distinguish polymorphic code from a related, even more complex technique called metamorphic code.

Metamorphic Code: Code that, when it replicates, changes its entire structure and appearance, including its core logic or payload, while retaining its original functionality. It essentially "rewrites itself" with each new copy, not just its decryptor.

The key difference:

• Polymorphic: Mutates the decryptor and potentially the encryption key. The payload remains constant.
• Metamorphic: Mutates the entire body of the code, including the core malicious logic (the 'payload' in the polymorphic sense). There might not even be a separate decryptor/payload structure; the code simply transforms itself.

Metamorphic code is significantly harder to detect, as even emulation might yield a different-looking executable code block in memory each time, requiring behavioral analysis or complex code comparison techniques. Polymorphic code is fundamentally self-modifying code that focuses its mutation on the part responsible for revealing the static core.

Self-Modifying Code: Code that alters its own instructions in memory or on disk during execution. Both polymorphic and metamorphic code rely on self-modification.

Historical Context and Examples

The concept of polymorphic code is not new:

• The first known polymorphic virus, 1260, was written by Mark Washburn in 1990.
• A more influential polymorphic engine was developed by the hacker known as Dark Avenger in 1992. His engine allowed other virus writers to easily add polymorphic capabilities to their own malware, significantly increasing the threat landscape.
• A more recent and notorious example of a virus heavily relying on polymorphism is the file infector Virut.

These historical examples highlight how quickly defensive measures (signature scanning) were countered by offensive techniques (polymorphism), driving the continuous evolution of both malware and security software.

Where Polymorphism is Used (and Why it's Underground)

While the technique of self-modification and code generation has legitimate uses (like just-in-time compilers, specialized installers, or even some forms of digital rights management), the specific application of polymorphism – mutating code to evade signature detection – is overwhelmingly associated with malicious software:

• Viruses and Worms: To make different infected copies harder to detect.
• Shellcode: Small pieces of code often used in exploits to gain control of a system. Polymorphic shellcode changes its appearance to avoid detection by network intrusion detection systems (IDS).
• Loaders/Droppers: Small initial pieces of malware whose only job is to download and execute the main payload. Polymorphism helps the loader evade detection long enough to get the main threat onto the system.

Because its primary purpose is to bypass security and facilitate harmful activities, the detailed construction and deployment of polymorphic engines are rarely discussed openly in standard programming curricula. Understanding how it works, however, is essential for anyone involved in cybersecurity defense. It's a powerful tool in the digital cat-and-mouse game, representing a significant step in malware sophistication.

---